All web applications for web browsers are associated with an “Origin”. The Origin of a web application is the server or domain from which the web application originates. The “Origin concept” is well established and described in the context of web browsers and web applications. Formerly, a “Same Origin” policy was applied for web browsers, which implied that a web application employed in a web browser could only request and retrieve data from the Origin from which the web application was loaded. The Same Origin policy was applied in order to prevent “malicious” applications from retrieving non-public information via a client, e.g. from the intra-network of a company, as illustrated in FIG. 1.
FIG. 1 illustrates a scenario according to the prior art were the Same Origin policy is not applied. A suspicious web application 104 is loaded in a browser on a company intranet by an unsuspecting user. When being loaded in the browser, the suspicious web application 104 may access and “steal” information from the company's intranet 106 without the user's knowledge.
For example, applying the Same Origin policy prevents malicious or fraudulent web pages or applications from obtaining personal user data from a user being logged in to a popular social networking site, such as e.g. “Facebook”, in the same browser, given that the malicious or fraudulent web pages have other Origins than the social networking site. However, the Same Origin policy is not compatible with the desire of many application developers to create web applications which collect and use data from one or more Origins, other than the Origin from which the web application was loaded.
In order to enable web applications to make requests, using XMIHttpRequest or similar, to other Origins than the Origin from which it was loaded, a mechanism to enable client-side cross-Origin requests has recently been defined in the W3C proposed standard document “Cross-Origin Resource Sharing” (CORS) [1].
The use of CORS or similar mechanisms enables e.g. client side “mash-ups” and the creation of applications that rely on a content server or Origin, which is distinct from the Origin of the application, e.g. to store its data. A “mash-up” is a web page or application that uses and combines e.g. data, presentation or functionality from two or more sources to create new service. When web applications are able to communicate directly with another Origin, as illustrated e.g. in FIG. 3, users who apply said web applications in a browser can also authenticate directly with those servers without the need for server-to-server authentication schemes such as OAuth (Open Authorization). One advantage of CORS is that a single provider, e.g. a content server, can act backend for a number of third-party applications, without them having to proxy the traffic thru their own Origins or servers. Such a proxy scenario is illustrated in FIG. 2.
However, when using CORS or similar, a potential problem could arise when two different applications (A 404 and B 406) from two Origins, 408 and 410, respectively, store and fetch their data in/from the same content server (X 412), to which a user of A and B is authenticated. This situation is illustrated in FIG. 4. The user is authenticated directly towards the content sewer X, which typically means that any request to X carrying the authentication token (typically a cookie) is valid. Consequently, a user which authenticates towards X when entering X via A, would already be “logged in”, i.e. authorized, if she or he later navigated to B, when using the same web browser 402. This may imply that application B can access any user-related data 414 stored on X without the need for the user's authorization. For example, B would be able to access data belonging to application A.
For example, when a user, which is logged in to a Popular Social Networking Site (PSNS), navigates to a popular news site, e.g. “CNN”, the user may there get to see which of her or his PSNS “friends” that are currently browsing CNN. This is possible, since the PSNS credentials are stored in the browser, and may thus be included when the browser makes a request towards another Origin on behalf of CNN. Thus, the news site CNN may get access e.g. to a record of the PSNS “friends” of the user, without the user having authorized such an access. CNN may then map the record of PSNS “friends” against all other PSNS-authenticated users visiting the news site, and thus display which of the user's “friends” that are currently browsing CNN. In this case, the news site would have registered with the PSNS, in order to be allowed to fetch information using COBB. However, such a registration can easily be made for any application, also for fraudulent applications.
It may be desired that two applications A and B share user data with each other, but, it may just as well be undesired that A and B share data, by e.g. a provider of at least one of the applications and/or by the user. Therefore, the above described possibility for e.g. fraudulent applications to make authorized requests is identified as a security risk.